
PATENT 

Attorney Docket No.: P2807 
Client/Matter No.: 80168.0210 
Express Mail No. EV322529053US 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 
BEFORE THE BOARD OF PATENT APPEALS AND INTERFERENCES 



Appl. No. 

Applicants 

Filed 

TC/A.U. 

Examiner 

Docket No. 

Customer No. 



09/546,993 
David P. Tong 
April 11,2000 
2672 

Faranak Fouladi Semnani 
P2807 
32658 



Mail Stop AF 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 



Confirmation No. 4578 



Title: Method and Computer 
Program Product for Reducing 
Colormap Flashing 



REPLY UNDER 37 CFR 1.116 
Expedited Procedure 

RECEIVED 

DEC 1 1 2003 

Technology Center 2600 



APPELLANT'S SUPPLEMENTAL APPEAL BRIEF 

I. Real Party in Interest 
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USA 

II. Related Appeals and Interferences 
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directly affect, be directly affected by, or have a bearing on the decision to be 
rendered by the Board of Patent Appeals and Interferences in the present appeal. 
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III. Status of Claims 

Claims 1 and 3-8 are pending in the application. Original claim 2 was 
cancelled. No claims have been allowed. Claims 6 and 8 stand rejected under 35 
U.S.C. §102 as being anticipated by U.S. Patent No. 5,703,627 to Young. Claims 1, 
3-5, and 7 stand rejected under 35 U.S.C. §103 as being unpatentable over Young 
further in view of U.S. Patent No. 5,406,310 to Aschenbrenner. On May 30, 2003, 
Appellant appealed from the final rejection by filing a Notice of Appeal of all pending 
claims 1 and 3-8. 

IV. Status of Amendments 

In response to the Final Office Action mailed March 25, 2003, Appellant 
amended claims 1, 3, and 6-8 and cancelled claim 2. In an Advisory Action mailed 
April 29, 2003, it was indicated that the amendments were entered and claim 2 was 
withdrawn from consideration. A second Final Office Action was mailed November 
18, 2003, apparently because the Examiner determined that the first Final Office 
Action was premature. However, the second Final Office Action retained the 
rejection of all claims based on the Young and Aschenbrenner references. Therefore, 
claims 1 and 3-8, as amended in the Amendment and Response to Final Office Action 
mailed April 14, 2003, remain in the application for consideration in this appeal. 

V. Summary of the Invention 

Briefly, the invention is directed toward a method, and associated system, for 
preventing colormap flashing by simulating allocation of a private colormap without 
actually ever developing or creating such a private colormap . As discussed at page 8, 
lines 1-23 of the specification, colormap flashing in prior art devices occurs when a 
switch is made between a default colormap and a private colormap. 

The invention does not use or allocate a private colormap. This is indicated in 
the system of Figure 2 which shows the use of a secondary lookup table 12 along with 
a default colormap 14 to respond to an application 16 requesting a private colormap to 
control the display 1 8 without flashing. The claimed method is described with 
reference to Figures 4 and 5, and as stated at page 13, lines 16-19, the method enables 
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satisfaction of a request for allocation of a private colormap to be satisfied "without 
having to overwrite or 'switch out' the default colormap from the frame buffer" and in 
this manner, "colormap flashing is eliminated." 

As discussed in the specification at page 10, lines 13-19 with reference to 
Figure 4B, simulating allocation of a private colormap "involves transparently using a 
secondary lookup table. . .having entries which are mapped to the entries of the default 
colormap. This secondary lookup table is used so that the application 
program. . . 'believes 5 that it is still properly obtaining an allocated private colormap 
for its use, however, in actuality the default colormap is utilized." Referring to the 
specification at page 10, lines 19-23 with reference to Figure 4B, colormap flashing is 
prevented since in the method of the invention the " default colormap is retained in the 
frame buffer , rather than being swapped out. Instead of returning a 'private' 
colormap, the software returns a reference to the default colormap and then provides 
functionality so that the default colormap behaves like a private colormap." 

From Figure 4B, it can be seen the method involves an application requesting 
a color allocation in a default colormap. As described at page 1 1, lines 2-10 with 
reference to Figure 4B, if the application attempts to allocate a read-only color the cell 
can be shared with other applications typically by returning a closest match from the 
default colormap. Referring to Figure 5 at step 500, if a read-only cell is not 
requested, i.e., a private cell is requested at 504 that should not be shared, the method 
continues at 506 with providing a secondary lookup table. The allocation and 
mapping to the default colormap is described further at page 12, lines 3-22 of the 
specification. Several cells in the "simulated private colormap" may map to the same 
entry in the default colormap leading the application to believe the cells contain 
different colors. 
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At step 510 and as described at page 12, line 22, if there is no space available 
in the default colormap for a private color, then step 514 is performed to provide a 
closest match of the requested private color to a previously-stored read-only color. 
After associating the cell of the secondary look up table with the location of a cell in 
the default colormap, step 518 is performed to return the location of the cell to the 
requesting application as a reference to the secondary lookup table (see also the 
specification at page 13, lines 9-15). In this manner, private color allocation requests 
are satisfied without creation of a private colormap, which avoids the need for 
switching between a private colormap and the default colormap that can cause 
flashing. 

VI, Issues 

1. Whether claims 6 and 8 are unpatentable under 35 U.S.C. § 102(b) over 
Young (U.S. Patent No. 5,703,627). 

2. Whether claims 1, 3-5, and 7 are unpatentable under 35 U.S.C. § 103(a) 
over Young in view of Aschenbrenner (U.S. Patent No. 5,406,310). 

VII. Grouping of Claims 

The following groups of claims do not stand or fall together. 

Rejection under 102(b) : 

Group I : claim 6; and 
Group II : claim 8. 



Rejection under 103(a) : 

Group III : claim 3 ; 

Group IV : claim 1, 4, and 5; and 

Group V : claim 7. 
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VIII. Argument 

A. Rejection of Claims 6 and 8 under 102(b) based on Young is Improper 



Independent claim 6 calls for a method that includes, among other things, 
"transparently simulating the allocation of the private colormap using a default 
colormap." Significantly, the simulating includes "allocating a secondary lookup 
table comprising entries mapped to entries in the default colormap." Young does not 
teach simulating a private colormap (rather than actually creating one) including 
allocating a secondary lookup table with entries mapped to entries in a shared default 
colormap. Accordingly, Appellant requests that the rejection of claim 6 (Group I) 
under 35 U.S.C. § 102 over Young be withdrawn. 

In the Final Office Action mailed March 25, 2003, claim 6 was rejected based 
on Young, which (on page 4 of the Office Action) was said to disclose the claimed 
invention at col. 6, lines 57-62, col. 5, lines 2-5, and the Abstract at lines 1-28. The 
Office Action further stated that "Young also discloses in col. 5 lines 57-62 that color 
values from private color map being copied into free cells of a shared default map." 
Additionally, in the last line of the Advisory Action, it is stated that "Young discloses 
the creation of a colormap for private use" and in "addition there is no detail on any 
differences between a secondary lookup table and a private colormap in the 
specification and furthermore these two name [sic] represent the samething [sic] in the 
art." 

Appellant agrees that Young teaches the use of private colormaps , but 
Appellant disagrees that a private colormap and use of a secondary lookup table are 
equivalents. The difference between the use of a private colormap and simulating a 
private colormap using the default colormap is an important element of the described 
and claimed invention used to prevent colormap flashing. As defined at page 3, lines 
1-2 of the specification, a "private colormap" provides a client device a "full set of 
256 cells that are not shared with any other client" and which is stored in the frame 
buffer. In contrast, simulating a private colormap is performed according to claim 6 
by allocating a secondary lookup table mapped with entries in the default colormap, 
i.e., a location or reference to a cell in the default colormap is stored in the secondary 
lookup table rather than a color value as would be the case in a private colormap. As 
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noted at page 10, line 14, the secondary lookup table can be stored in conventional 
memory. During operation 516 of Figure 5, a cell in the secondary lookup table is 
associated or mapped with the location of the cell from the default colormap and a 
private color value is not actually stored in the cell as would be the case for a private 
colormap. Often, a closest match is used and mapped to the secondary lookup table 
rather than assigning a new color or color value as would be the case with a private 
colormap. As a result, there will not be a difference between colors in the simulated 
private colormap (which points to default colormap cells) and colors in the default 
colormap, which avoids flashing during colormap switching. 

More specifically, Young at the citations provided by the Examiner does not 
teach simulating the allocation of the private colormap using a default colormap 
including allocating a secondary lookup table comprising entries mapped to entries in 
the default colormap as called for in claim 6. The Abstract of Young makes it clear 
that Young is attempting to solve the flashing problem by making the default 
colormap contain the same color values as private colormaps (e.g., at line 1 1 "Since 
the default colormap 5 s copied cells are the same as corresponding cells in the private 
map they do not flash. . ."). This is achieved by a process labeled "residual color 
allocation" to fill unallocated cells in the default colormap with color values allocated 
to private colormap cells. Young was also cited at col. 5, lines 2-5, but at this point, 
Young is again discussing the residual color allocation method of minimizing flashing 
"by copying color values from a private color map into free cells of a shared default 
map." Young is not teaching that a creation of a private colormap should be avoided 
and is not teaching or suggesting that it may be useful to provide references to the 
cells in a default colormap to an application such that a number of applications are all 
using the default colormap. The Examiner further cited Young at col. 6, lines 57-62, 
but Young at this point is merely discussing the use of color allocation and default 
colormap sharing with no discussion of the use of a secondary lookup table 
"comprising entries mapped to entries in the default colormap." Claim 6 is not 
anticipated by Young because all of the elements of the claimed method are not 
taught. 

In the November 18, 2003 Final Office Action in the chart on page 8, the 
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Examiner again states that "Young teaches that the client creates a colormap for 
private use." Appellant finds this to be further evidence that Young fails to teach 
simulating a private colormap with a secondary lookup table mapped to the default 
colormap as called for in claim 6, but instead, Young is teaching the actual creation 
and use of a private colormap which is avoided by the claimed method. The 
November 18, 2003 Final Office Action further states at page 9, lines 10-13 that 
creating a colormap for private use is the same as "allocating a secondary lookup table 
mapped to entries in the default colormap." Appellant disagrees and believes that the 
specification and the claims provide ample language to distinguish Young from claim 
6, and specifically, the use of a private colormap leads to the flashing problem being 
addressed by Appellant's method of claim 6. 

As with claim 6, independent claim 8 calls for transparently simulating the 
allocation of a private colormap using a default colormap including allocating a 
secondary lookup table. However, claim 8 (Group II) is believed to be separately 
patentable relative to claim 6 (Group I) because claim 8 calls for the secondary lookup 
table to store "information received from the application program relating to the 
intercepted request." A further patentable difference is that the allocation simulating 
"includes associating a cell in the secondary lookup table with a location of a cell in 
the default colormap and returning the location of the cell in the default colormap to 
the application program as a response to the intercepted request ." These limitations 
are not called for in claim 6 yet they further distinguish the method of claim 8 from 
the teaching of Young. 

In the first Final Office Action, claim 8 was rejected under 35 U.S.C. §1 12. In 
the Advisory Action, the §112 rejection was held to be overcome, but claim 8 was 
then rejected under § 102(b) as being anticipated by Young. An element-by-element 
analysis was not provided but instead Young was cited generally at col. 5, lines 2-25 
and Abstract lines 1-28. Appellant does not believe Examiner met the burden 
required for making a proper anticipation rejection. The second Final Office Action 
on page 10 provided an element by element analysis, but Appellant believes this again 
provides evidence that the Examiner is confusing simulating a private colormap with 
actually providing one. 
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As discussed with reference to claim 6, Young does not teach simulating the 
allocation of a private colormap but instead in the Abstract discusses how cell 
contents of a created private colormap can be copied into the default colormap. Also, 
at col. 5, lines 2-25, Young provides a further description of how color values in the 
cells of private and default colormaps can be maintained to be the same to control 
flashing. No teaching of a secondary lookup table is provided in Young. 
Accordingly, Appellant requests that the rejection of claim 8 (Group II) under 35 
U.S.C. § 102 over Young be withdrawn. 

More particular to claim 8, Young does not teach that simulating a private 
colormap may include "storing information received from the application program 
relating to the intercepted request." The Examiner in the second Final Office Action 
stated on page 10 that Young teaches that the client stores colors it needs into the 
private colormap. As can be seen from this statement, Young teaches the use of a 
private colormap not the simulation of one and use of colors in the default colormap 
to avoid flashing. Further, Young clearly does not teach returning the location of a 
cell in a default colormap to an application program as a response to a request for an 
allocation of private colormap. In contrast, Young (for example, in the Abstract) 
teaches allocating a private colormap in response to such a request (and then 
proceeding to modify the default colormap). For this additional reason, it is believed 
that claim 8 is not anticipated by Young. 

B ♦ Rejection of Claims 1, 3-5, and 7 under 103(a) based on Young in view 
of Aschenbrenner Improper 

Independent claim 3 calls for a computer program product that includes, 
among other things, computer readable code devices to cause a computer to effect 
transparently simulating the allocation of the requested private colormap "by 
providing a reference to a cell in a default colormap" "whereby creation of and 
swapping to the requested private colormap are not performed." Young alone (or in 
combination with Aschenbrenner) fails to teach or make obvious simulating a private 
colormap by providing a reference to a cell in a default colormap to avoid swapping 
and flashing. Accordingly, Appellant requests that the rejection of claim 3 (Group III) 
under 35 U.S.C. § 103 over Young be withdrawn. 
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In the first Final Office Action, claim 3 was rejected as reciting a computer- 
readable medium for executing the method of claim 1, which would have been 
obvious to one skilled in the art to port the method to other computer systems. In 
rejecting Claim 1, Young was cited at col. 6, lines 57-62, col. 5, lines 2-5, and the 
Abstract lines 1-28. An element by element analysis was later provided in the second 
Final Office Action. As note for claims 6 and 8, the Examiner states that "Young 
teaches that the client creates a colormap for private use", which Appellant agrees 
with but believes shows clearly that Young does not simulate creation of a private 
colormap as called for in claim 3. Aschenbrenner is cited for the idea of "closest 
matching" so does not appear to be relevant "to the rejection of claim 3. 

As discussed with reference to claims 6 and 8, the Abstract of Young makes it 
clear that a private colormap is created for a requesting application, and this is used by 
the Examiner in rejecting claims that require simulation of such creation. This is in 
direct contrast to the limitations of claim 3 "whereby creation of. . .private colormap 
are not performed." Further, at the other cites, Young teaches a residual color 
allocation in which color values of a private colormap are copied into unallocated 
cells of a shared default colormap. There is no teaching of "providing a reference to a 
cell in a default colormap" as called for in claim 3. Because a private colormap is 
created in Young for storing color values there would be no reason or motivation to 
return a reference to the default colormap to an application requesting allocation of a 
private colormap (instead you would simply respond by creating the private colormap 
and allocating new colors). Because each feature of claim 3 is not taught or even 
suggested by Young, claim 3 is believed to be non-obvious in light of the reference 
and allowable. 

Independent claim 1 is similar to claim 3 in calling for a method that involves 
simulating the allocation of a private colormap and is believed allowable over Young 
for the reasons provided for claim 3. Claim 1 is also believed to be separately 
patentable relative to claim 3 because it includes a number of specific steps in the 
simulating of the allocation of the private colormap not required in claims 3 and not 
shown in Young or Aschenbrenner. 

9 
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Specifically, claim 1 calls for the simulating to includes: storing the 
secondary lookup table information received from said application program relating to 
one or more requested colors privately allocated by the application program; 
performing a closest match of said requested color to a color stored in the default 
colormap; and returning the closest match to the application program. The 
combination of these elements is not shown or even suggested in Young in view of 
Aschenbrenner. Hence, Appellant requests that the rejection of claim 1, as well as 
dependent claim 5 and claim 4 which depends from claim 3 but has limitations similar 
to claim 1 (i.e., Group IV), under 35 U.S.C. § 103 over Young in view of 
Aschenbrenner be withdrawn. 

In the Advisory Action, Young was cited at col. 5, lines 2-25 and Abstract 
lines 1-28 for teaching the claimed feature of simulating allocating a private colormap 
using a default colormap including allocating a secondary lookup table for storing 
information received from the application. As discussed with reference to claims 3, 6, 
and 8, Young provides no teaching in the Abstract, at col. 5 lines 2-25, or elsewhere 
of allocating a secondary lookup table as part of simulating allocation of a private 
colormap. Instead, Young teaches actual creation of a private colormap for an 
application not its simulation. In the second Final Office Action, the Examiner 
clearly states that they agree with this interpretation of Young by stating at page 4, 3 rd 
paragraph that "Young teaches that the client creates a colormap for private use." 
Further, as discussed relative to claim 8, Young fails to teach or suggest storing 
information received from the application as part of the allocation process. Because 
the method of claim 1 is not obvious in light of Young, claim 1 is believed allowable. 

In the Advisory Action and second Final Office Action, Aschenbrenner was 
cited at col, 6 lines 22-31 and col. 6 lines 48-51 for teaching the finding of a closest 
match of a requested color in a default colormap. It was then asserted by the 
Examiner that it would be obvious to modify Young with the teaching of 
Aschenbrenner to arrive at the method of claim 1 . Appellant argues that 
Aschenbrenner fails to overcome the shortcomings of Young. Specifically, 
Aschenbrenner does not teach the use of a secondary lookup table to simulate 
allocation of a private colormap, and thus, the combination cannot teach or suggest all 
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the elements of claim 1 . 



Additionally, in the closest color set process described in Aschenbrenner at 
col. 6, lines 22-31, the user must select or choose the closest color routine which 
causes the process to be visible or not transparent. According to Aschenbrenner, 
image colors that cannot be loaded into a default table that were requested by an 
application program are compared against the colors in the default table and then the 
closest match is "substituted for the unloaded color" and then, according to Figure 5, 
the default table is transferred to the display table. There is no teaching of returning 
the closest match results to the requesting application as required in claim 1 . Hence, 
claim 1 is believed allowable because at least the closest match and closest match 
returning portions of the allocation simulating are not shown or made obvious by the 
combination of Young and Aschenbrenner. 

Claim 5 depends from claim 1 and is believed allowable for at least the 
reasons for allowing claim 1. Claim 4 depends from claim 3 but also has limitations 
similar to claim 1 and is, thus, believed allowable for the reasons for allowing claims 
1 and 3. 

Claim 7 (Group V) depends from claim 1 and is believed allowable for the 
reasons provided for allowing claim 1 . Further, claim 7 is believed separately 
patentable. Claim 7 provides additional protection for the inventive idea of treating 
read-only color cell requests differently than other requests. Young and 
Aschenbrenner do not show this feature nor would it be obvious to one skilled in the 
art how to modify their teachings to obtain the claimed invention. According to the 
invention (see, for example, Figures 4B and 5) and claim 7, if a client requests a read- 
only color then a closest match is performed rather than allocating the requested color 
(by taking up unallocated cell in the default map). Accordingly, Appellant requests 
that the rejection of claim 7 (Group V) under 35 U.S.C. § 103 over Young in view of 
Aschenbrenner be withdrawn. 

More specifically, claim 7 calls for determining whether the requested color 
was for a read-only color cell. If for a read-only request, skipping the storing step and 
performing the closest match and returning the results. If not for a read-only request, 
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performing the storing if space is available otherwise performing the closest match 
and returning the results. In the Advisory Action and second Final Office Action, 
Aschenbrenner was cited (again at col. 6 lines 22-31 and col. 6 lines 48-51) for 
teaching closest color matching. It was then argued that it would have been obvious 
to modify Young with Aschenbrenner 5 s teaching "to be able to always find a color for 
the image colors even if the colormap is full." 

However, claim 7 is directed to more than just finding a color when a default 
colormap is full. Claim 7 requires that a simulation of a private colormap be 
performed in a manner that treats read-only requests differently from other requests. 
In the claimed method, the default colormap is used and "private" colors may be 
stored if space is available otherwise a closest match and simulation is performed. 
The Examiner has not pointed to anything in Young or Aschenbrenner that discusses 
that read-only requests and non-read-only requests are treated differently. For this 
additional reason, claim 7 is believed allowable over Young and Aschenbrenner. 

Conclusion 

In view of all of the above claims 1 and 3-8 are believed to be allowable and 
the case in condition for allowance and it is respectfully requested that the Examiner's 
rejections be overturned. 



Respectfully submitted, 



Date: December 8, 2003 




Kent A. Lembke, Reg. No. 44,866 

HOGAN & HARTSON LLP 

One Tabor Center 

1200 17th Street, Suite 1500 

Denver, Colorado 80202 

Phone: (720) 406-5378 

Fax: (720) 406-5301 
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IX. APPENDIX OF CLAIMS ON APPEAL 

1 . A method of reducing colormap flashing on a display system, the 
display system having a frame buffer which provides a single hardware colormap, the 
method comprising the steps of: 

intercepting a request from an application program for an allocation of a 
private colormap; and 

transparently simulating the allocation of the private colormap using a default 
colormap, wherein the default colormap is retained in the frame buffer during the 
simulating and the simulating includes allocating a secondary lookup table for storing 
information received from the application program relating to the intercepted request; 
and 

wherein said step of transparently simulating the allocation of a private 
colormap further comprises: 

storing in the secondary lookup table information received from said 
application program relating to one or more requested colors privately allocated by 
said application program; 

performing a closest match of said requested color to a color stored in said 
default colormap; and 

returning said closest match to said application program. 

2. (cancelled) 
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3. A computer program product, comprising: 
a computer usable code storage medium; 

computer readable code embodied in said storage medium for reducing 
colormap flashing on a display system, the display system having a single hardware 
colormap, the computer readable code comprising: 

computer readable code devices to cause a computer to effect 
intercepting a request from an application program for an allocation of a 
private colormap; and 

computer readable code devices to cause a computer to effect 
transparently simulating the allocation of the requested private colormap by 
providing a reference to a cell in a default colormap and retaining the default 
colormap in a buffer, whereby creation of and swapping to the requested 
private colormap are not performed by the computer program product. 

4. The computer program product of claim 3, wherein said computer 
readable program code devices configured to cause a computer to effect transparently 
simulating the allocation of a private colormap further comprises: 

computer readable code devices to cause a computer to effect allocating a 
secondary lookup table for storing information received from said application 
program relating to one or more requested colors privately allocated by said 
application program; 

computer readable code devices to cause a computer to effect performing a 
closest match of said requested color to a color stored in said default colormap; and 
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computer readable code devices to cause a computer to effect returning said 
closest match to said application program. 

5. The method of claim 1, comprising the step of determining whether a 
private color cell has been requested by the application program and writing said 
private color cell to the default colormap. 

6. A method for reducing colormap flashing on a display system, the 
display system having a frame buffer which provides a single hardware colormap, the 
method comprising the steps of: 

intercepting a request from an application program for an allocation of a 
private colormap; 

transparently simulating the allocation of the private colormap using a default 
colormap, wherein the simulating includes allocating a secondary lookup table 
comprising entries mapped to entries in the default colormap; and 

determining whether a private color cell has been requested by the application 
program and writing said private color cell to the default colormap. 

7. The method of claim 1, further including prior to performing the 
storing, determining whether the requested color was for a read-only color cell, when 
determined not a read-only request, performing the storing and only performing the 
performing the closest match and the returning when a space is not available in the 
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default colormap, and when determined a read-only request skipping the storing and 
performing the performing the closest match and the returning the closest match. 

8. A method of reducing colormap flashing on a display system, the 
display system having a frame buffer which provides a single hardware colormap, the 
method comprising the steps of: 

intercepting a request from an application program for an allocation of a 
private colormap; and 

transparently simulating the allocation of the private colormap using a default 
colormap, wherein the default colormap is retained in the frame buffer during the 
simulating and the simulating includes allocating a secondary lookup table for storing 
information received from the application program relating to the intercepted request; 

wherein the simulating includes associating a cell in the secondary lookup 
table with a location of a cell in the default colormap and returning the location of the 
cell in the default colormap to the application program as a response to the intercepted 
request. 
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